Many software programs and online services have graphical user interfaces (GUIs) with which users can interact and receive displayed information. While it was originally the case that the software engineers (also referred to as “developers”) that created the software code for an underlying program also developed the corresponding GUI, it is increasingly the case that non-technical personnel other than the software engineers may design at least portions of GUIs. Such non-technical GUI designers may include various types of personnel in different situations, such as psychologists that specialize in optimizing human-computer interfaces or business people serving as product managers for products with software or online service components.
Unfortunately, existing techniques for generating GUIs do not facilitate the interaction of multiple distinct personnel, such as non-technical GUI designers and technical GUI developers. For example, non-technical GUI designers can simulate the visual appearance of GUIs in various ways, such as by using drawing or desktop publishing programs to manually specify the appearance of various GUI elements (e.g., buttons, scroll bars, pop-up windows, drop-down menus, text input areas, tables, charts, images, video, text display areas, etc.) that are part of that GUI. In addition, there may even be software tools available to GUI designers that are specifically designed to assist in the creation of simulated GUI appearances, such as by providing visual representations of various GUI elements that can be added (e.g., via drag-and-drop interactions) to a simulated GUI. However, although such techniques allow a GUI designer to specify a simulated appearance of a GUI, it can be difficult or even impossible for GUI developers to generate an actual GUI that has the same appearance, such as due to complexities of the simulated appearance or to aspects of the simulated appearance that do not accurately represent the display capabilities and/or functionality of an actual GUI.
In addition, existing techniques allow GUI developers to create actual GUIs in various ways. For example, software development tools may allow GUI developers to specify underlying GUI objects corresponding to GUI elements to be displayed as part of an actual GUI. The GUI elements may be of various types, and the corresponding GUI objects may include various information to support the display of those GUI elements. For example, some GUI elements display data (e.g., from an external data source such as a database), and the software developer can specify information relating to data to be displayed (e.g., data bindings for accessing an external data source, or information for selecting and/or formatting data for display) for a corresponding GUI object. In addition, some GUI elements respond to interactions with users in various ways, provide various functionality, and/or have various types of inter-dependencies with other GUI elements, and the software developer may be able to specify information for corresponding GUI objects to provide those interaction responses, functionality and inter-dependencies (e.g., indications of software routines for handling various types of interactions or events). However, while such techniques allow GUI developers to specify the underlying GUI objects that can be used as part of an actual GUI, they do not easily allow non-technical GUI developers to participate in the generation of such actual GUIs.
A variety of software development tools (or “SDTs”) are available to GUI developers (e.g., the Siebel Tools portion of Siebel eBusiness Applications version 7, commercially available before June of 2001), and can provide a variety of additional functionality to assist in the creation and/or modification of software programs that include actual GUIs.
Some SDTs may abstract software to be generated in various ways, and may then provide functionality related to that abstraction. For example, some SDTs may support a layered architecture in which objects in a given layer depend on objects in the next lower layer and are insulated from other layers in the structure. One such layered structure includes a logical user interface objects layer (e.g., that includes user interface objects to define the visual interface that a user sees and interacts with), a business objects layer (e.g., that includes business objects to combine data from data objects into logical data constructs for presentation to the user by user interface objects), and a data objects layer (e.g., that includes data objects to provide a logical representation of data structures from underlying databases in order to provide access to those data structures by business objects). SDTs with such a layered structure may allow corresponding objects to be defined at some or all of the layers as part of a software program being generated.
Objects can also be used in various ways by SDTs, such as by having each object implement one piece of a software program being generated. Such software program pieces implemented by objects may include, for example, an element of a user interface (e.g., a popup window for record selection), an abstract data representation (e.g., a database column), or a direct database representation or construct (e.g., a join relationship between database tables). Properties of such an object may represent characteristics of the software construct that the object implements (e.g., the name, data type, and length of a database column, or the title bar caption of a popup window). Some SDTs may also support hierarchical (or parent-child) relationships between different objects, such as when a parent object represents a table and child objects represent columns of the table.
SDTs may represent created objects in various ways, such as with a set of properties having assigned values. The created objects may be implemented directly as an object in an underlying object-oriented programming language (e.g., C++), or instead may be abstracted in various ways. In addition, some or all objects may have assigned sets of behaviors, such as by having an associated set of one or more software routines (e.g., via a DLL assigned to the object). An SDT may also provide one or more existing objects, such as a core set of objects, and allow a user to use those existing objects as a basis for an application being generated.
In addition, some SDTs may support having object types from which objects of that type can be created, with the object types having defined sets of properties. Objects created from an object type may have values for each of the properties of the object type, such as user-specified or default values, and may be limited by some SDTs to having values only for the properties of the corresponding object type. In some SDTs, object types may also have parent-child relationships with other object types, with a parent object type able to have numerous children object types. An SDT may also provide one or more existing object types, such as a predefined set of object types that have specific purposes (e.g., an applet object type for “applets” that define a user interface unit, or a business component object type for business objects that each define a data record structure from one or more database tables).
Some SDTs may also support generating multiple different projects, and if so may associate some or all objects being created with one or more projects (e.g., to associate objects that are part of an application being created with the project to which that application is associated).
SDTs may also provide a variety of tools to assist in viewing and/or manipulating (e.g., adding, editing and deleting) objects, such as an object editor window that displays a table in which each row represents an object and each column represents a property of that object. A property setting for an object may be changed by clicking the corresponding cell in the table and supplying a new value (e.g., that is manually entered or selected from a pick list), and objects may be added to or deleted from the table. Some SDTs may also provide a properties window that provides additional details about the properties of a specific object, such as an object selected in the object editor window (e.g., a selected row of the table). In a similar manner, some SDTs may provide tools for viewing and/or manipulating object types, such as an object explorer window that uses a visual metaphor for displaying hierarchical object type relationships that is similar to that of the Windows Explorer program in Windows 2000 or NT. Such an object explorer window may operate in parallel with a corresponding object editor window, such as by displaying objects of a particular type in the object editor window when that object type is selected in the object explorer window.
In addition, some SDTs may provide various tools to assist in creating objects. For example, software wizards may be provided for each of various object types to step users through the process of creating and configuring objects of those types. In particular, a wizard may guide the user through providing various types of information, and then use that information to specify property settings for the object being created. Different wizards may be available from some SDTs for a variety of object types, such as table applets, chart applets, tree applets, form applets, multi-value group applets, pick list applets, views, screens, etc. In addition, tools may be available to validate created objects to help ensure that the objects are logically consistent, such as to check for invalid references to other objects.
As mentioned above, some SDTs may allow logical user interface objects to be specified for a software program in order to define the visual interface that a user of the software program will interact with. Such user interface objects may present data to users for viewing and/or modification, such as data from business objects. A variety of user interface elements may be represented by user interface objects, including control toolbar and menu elements, dropdown lists, view tabs, screen tabs, menu buttons, control buttons, etc.
One example of a type of logical user interface object in some SDTs is an “applet” object type that is used to implement higher-level user interface elements composed of lower-level user interface elements, such as data controls, editable scrolling tables, forms for data entry, business graphics, pop-up windows for multi-value groups and record selection, etc. that are composed of controls such as a text box, check box, command button, etc. For some SDTs, an applet provides access to the data of a single business component (e.g., for viewing, editing, and modifying fields in the business component), and may be able to be configured to allow data entry for a single record, to provide a scrolling table displaying multiple records, or to display business graphics or a navigation tree.
Some SDTs may also support a “view” user interface object type that is used to present one or more other user interface objects (e.g., applet objects) together at one time in a predefined visual arrangement and logical data relationship. Views may have names, and in some user interfaces may be selected by name from menus and/or displayed tab symbols. For some SDTs, each view is mapped to a single business object, and if so each applet in such a view may map to a business component in that business object.
Some SDTs may also support “screens” that are a collection of one or more related views, such as with an appropriate screen user interface object type. For some SDTs, all views in some or all screens are mapped to the same business object. In addition, for some SDTs a screen is not a visual construct itself, but is instead a logical collection of views to be displayed together.
Some SDTs may use a collection of screens as a user interface for a software program (or “application”). In some situations, an application may have one or more associated URLs that a user may specify to access the application, such as when a Web engine will be used to generate HTML pages to present the screens. One or more page tabs may be displayed, with each page tab object associated with a screen of the application.
Some SDTs may also provide additional functionality to assist in creating user interfaces, such as templates that define the layout and formatting of various elements of the user interface, tags that are inserted in templates to specify how objects should be laid out and formatted for that template, cascading style sheets that define how HTML or XML elements and their contents should appear in a Web document, etc.
In addition to the previously described tools to assist in viewing and/or manipulating objects, some SDTs may also provide tools to assist in specifying a layout of elements of a user interface and/or to display objects (e.g., pages, applets, views, etc.) in a manner similar to their actual appearance when displayed (e.g., in a WYSIWYG manner). For example, some SDTs may provide layout windows for various types of objects (e.g., views, applets, screens, and menus) to allow a user to modify and/or construct objects of that type by dragging and dropping other objects onto a representation of that object, such as based on an associated template that has placeholders for the objects being added. An applet layout window allows controls to be added to an applet, a view layout window allows applets and controls to be added to a view, and a screen (or “page”) layout window allows views and controls to be added to a screen. Indications of the objects to be added (e.g., views, applets and controls) may also be displayed in various ways. Some SDTs may also provide tools to modify existing templates and/or to create new templates, as well as to associate templates with objects as needed.
Thus, while various existing techniques assist in generating GUIs, they do not facilitate the interaction of multiple distinct personnel such as non-technical GUI designers and technical GUI developers. Accordingly, it would be beneficial to provide techniques to allow multiple personnel to participate in the creation of a GUI, such as to allow a non-technical GUI designer to create a prototype GUI that can be easily converted into an actual GUI whose appearance when displayed matches the appearance of the prototype GUI.